NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/142

Internet Message Format | 1996-08-06 | 3.8 KB

From: [e-mail] (Joe Buck)
Message-ID: <4e8g4t$[e-mail]>
X-Original-Date: 25 Jan 1996 17:54:37 GMT
Path: in2.uu.net!bounce-back
Date: 26 Jan 96 04:56:51 GMT
Approved: [e-mail]
Newsgroups: comp.std.c++
Subject: Re: Give operator. a chance
Organization: Synopsys Inc., Mountain View, CA 94043-4033
References: <[e-mail]>
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBFAgUBMQhgPeEDnX0m9pzZAQFuvAGAju5TDq3YHUH8hirK7WC0GeuI9w4OpKtx
    5MhRoJovKvd6B3cqTjVpG28m13Tc8R25
    =4KRC

Dan Holmsand <[e-mail]> writes:
>Is operator.() banned from the standards discussion?

Yes, I suppose it is, but since you brought it up I'll discuss it anyway.

A formal proposal to add it (from Jim Adcock of Microsoft) was voted down
some time ago.  The Adcock proposal was quite simple: "operator dot" would
work just like operator-> except that where operator-> returns a pointer,
operator. would return a reference.  The language in the standard would
be almost identical except for simple substitutions of words.  The
advantage of this was that it would be absolutely clear what the
modification would mean and what the language should be.

Some committee members objected that it's against the philosophy of C++ to
change the meaning of a builtin operator ("."  operating on class object)
-- though we already have operator& whose builtin meaning can be changed.

Others favored a more complex and non-orthogonal version, or, worse, first
said the proposal should be more complex and non-orthogonal and then
objected to the complexity and non-orthogonality in this modified version.

Others objected that if both operator. and operator-> were overloaded the
class would be just about impossible to implement, ignoring the fact that
no one (who understands that providing operator-> gives your object
pointer semantics and operator. gives your object reference semantics, and
you'd want to choose only one) would do this.

Others (those I respect the most) just said they didn't want extensions
without an extremely strong reason, didn't see a strong enough reason for
operator dot, but just wanted to get C++ standardized.  This does make
sense (it would make more sense if so many *other* extensions had not been
accepted).

I think that this rejection was a mistake, as the lack of operator dot
complicates the implementation of delegation (e.g. in classes that use a
reference-counted representation object where the representation object
has virtual functions).  I subscribe to the "write things once"
philosophy, and hate long lists like

class Foo {
private:
    FooRep * rep;
public:
    ...
    void foo() { rep->foo();}
    int bar(int arg) { return rep->foo(arg);}
    ... and about a dozen more
};

With operator. this would become

class Foo {
private:
    FooRep * rep;
public:
    FooRep& operator.() { return *rep;}
};

and now you can call foo(), bar(int) etc on objects of class Foo.  It
is possible, but confusing, to use operator-> here, but then the Foo
object looks like a pointer, and this isn't the type of programming
interface that is desired in this situation.

But it's too late for major changes at this stage; what's more important
is to complete the standard.  We lost the vote, and it's time to move on.

In the meantime, anyone who wants to experiment with the idea can probably
track down g++ patches that implement operator dot along the lines of
the Adcock proposal -- I've seen mention of these on the net, but I
don't know where they are.

--
-- Joe Buck     <[e-mail]>    (not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.       -- Vaclav Havel
---
[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]